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Abstract — Implementing guidance, navigation, and control 
(GN&C) theory principles and applying them to the human 
element of project management and control is not a new 
concept. As both the literature on the subject and the real- 
world applications are neither readily available nor 
comprehensive with regard to how such principles might be 
applied, this paper has been written to educate the project 
manager on the “laws of physics” of his or her project (not 
to teach a GN&C engineer how to become a project 
manager) and to provide an intuitive, mathematical 
explanation as to the control and behavior of projects. This 
paper will also address how the fundamental principles of 
modern GN&C were applied to the National Aeronautics 
and Space Administration’s (NASA) Constellation Program 
(CxP) space suit project, ensuring the project was managed 
within cost, schedule, and budget. 1 ' 2 

A project that is akin to a physical system can be modeled 
and managed using the same over arching principles of 
GN&C that would be used if that project were a complex 
vehicle, a complex system(s), or complex software with 
time-varying processes (at times nonlinear) containing 
multiple data inputs of varying accuracy and a range of 
operating points. The classic GN&C theory approach could 
thus be applied to small, well-defined projects; yet when 
working with larger, multiyear projects necessitating 
multiple organizational structures, numerous external 
influences, and a multitude of diverse resources, modem 
GN&C principles are required to model and manage the 
project. 

The fundamental principles of a GN&C system incorporate 
these basic concepts: State, Behavior, Feedback Control, 
Navigation, Guidance and Planning Logic systems. The 
State of a system defines the aspects of the system that can 
change over time; e.g., position, velocity, acceleration, 
coordinate -based attitude, and temperature, etc. The 
Behavior of the system focuses more on what changes are 
possible within the system; this is denoted in the state of the 
system. The behavior of a system, as captured in the system 
modeling, when properly done will aid in accurately 
predicting future system performance. The Feedback 
Control system understands the state and behavior of the 
system and uses feedback to adjust control inputs into the 
system. The feedback, which is the right arm of the Control 

1 U.S. Government work not protected by U.S. copyright. 
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system, allows change to be affected in the overall system; it 
therefore is important to not only correctly identify the 
system feedback inputs, but also the system response to the 
feedback inputs. The Navigation system takes multiple data 
inputs and based on a priori knowledge of the inputs, 
develops a statistically based weighting of the inputs and 
measurements to determine the system’s state. Guidance 
and Planning Logic of the system, complete with an 
understanding of where the system is (provided by the 
Navigation system), will in turn determine where the system 
needs to be and how to get it there. With any system/project, 
it is critical that the objective of the system/project be 
clearly defined - not only to plan but to measure perform- 
ance and to aid in guiding the system or the project. 

The system principles discussed above, which can be and 
have been applied to the current CxP space suit develop- 
ment project, can also be mapped to real-world constituents, 
thus allowing project managers to apply systems theories 
that are well defined in engineering and mathematics to a 
discipline (i.e.. Project Management) that historically has 
been based in personal experience and intuition. This 
mapping of GN&C theory to Project Management will, in 
turn, permit a direct, methodical approach to Project 
Management, planning and control providing a tool to help 
predict (and guide) performance and an understanding of the 
project constraints, how the project can be controlled, and 
the impacts to external influences and inputs. This approach, 
to a project manager, flows down to the three bottom-line 
variables of cost, schedule, and scope and to the needed 
control of these three variables to successfully perform and 
complete a project. 
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1. Introduction to Project Management 

Why Is Project Management Important? 

Project Management is one of many fields that has evolved 
over the years from largely a management of labor, to a 
coordination of subcontractor labor and in recent years to an 
integration with other projects and programs while also 
maintaining requirements configuration management, 
schedule, budget, scope of work, etc. As the magnitude of 
projects and programs has grown in size and complexity 
along with the financial and schedule pressures, so too, has 
the need to develop tools and best practices to provide a 
better posture for successful completion. 

History / of Project Management 

“Managing projects is one of the oldest and most respected 
accomplishments of mankind. One stands in awe of the 
achievements of the builders of the pyramids, the architects 
of the ancient cities, the masons and the craftsmen of the 
great cathedrals and mosques, and of the might of the labor 
behind the Great Wall of China and other wonders of the 
world. People were riveted at the sight of the Americans 
landing on the moon. All of these endeavors are projects, 
like many thousands of similar task-oriented activities, yet 
the skills employed in managing projects, whether major 
ones such as those mentioned above or more commonplace 
ones, are not well known other than to the specialists 
concerned.” [1] While it is probably not healthy for project 
managers to individually view themselves and their job 
importance in such terms as these, it is worth noting that 
without the skills and insight to lead projects - large or 
small - to completion, none of these achievements would 
have been realized. The art of Project Management across 
the ages has been achieved through the innate skill of those 
leading the tasks via intuition and empirical observations of 
what worked and what did not. In recent years, however, it 
has been recognized that there are common traits to projects, 
tools, and methods that can be used to manage the projects 
and best practices to follow. 

What is the State of the Art in Project Management? 

The best practices and tools available to project managers 
have evolved and become quite sophisticated. Today we can 
characterize the state of the art for Project Management best 
practices to be counted among the ranks of the standards of 
the Project Management Institute (PMI), 3 which issues 
Project Management Professional (PMP) certification 
credentials to individuals who are practicing the art of 
Project Management 4 . Similarly, the tools for performing 
Project Management have evolved over time and developed 
into math-based theories based on the statistics of the 
project metrics to assess the health, status, progress, and 

3 The author has no affiliation to this organization and is not promoting 
such certification, but provides this as one such industry-accepted approach 
to education and certification of Project Management training. 
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Project Management is not yet a science; therefore, like most highly tuned 
skills, masterful Project Management is considered an art. 


likely end-of-project triad of cost, schedule, and scope. Such 
tools include detailed, resource-loaded schedules tied to 
work breakdown structures that are cross coupled with 
budgets, charge codes, labor distributions, organizational 
breakdowns, and earned value metrics that weigh the 
relative relationships of the project metrics to assess the 
status and health of the project-based equations that were 
formulated from consistent historical observations. 

There are statistical tools, known as probabilistic risk 
assessments (PRAs), that are typically used to get a realistic 
look into the future using statistical likelihoods that are 
based on previously completed, relevant, programs and 
projects in which the final project metrics are used to 
estimate the project in question. While PRAs are usually 
used during project formulation to help bound the project 
and obtain the first realistic prediction of project life-cycle 
cost based upon desired confidence levels, PRAs can also be 
used midcourse in a project to obtain a clearer forecast of 
the project’s outcome given that more actual data is known 
of the project and some history exists from which to draw. 
However, it should be recognized that the usefulness of 
PRAs is limited to the independent historical project data 
they draw from and the relevance to the current project in 
question. Not all PRA tools are created equal or with the 
same a priori knowledge. It has been the author’s experi- 
ence with using PRAs at NASA [2] that they are useful as a 
thumbnail estimate, but that most of the PRA tools available 
are based upon commercial or military aviation projects. 
While these tools are somewhat similar in nature, the 
complexities, risks, and shear quantities are of completely 
different magnitudes when compared to human space 
programs during the last 50 years, the number of which can 
be counted on one hand. So, it is for the smart reader to read 
the fine print of the PRAs and use as appropriate. 

While Project Management best practices, surveillance, and 
prediction tools have been making headway in recent years, 
our fundamental understanding of the dynamics of projects 
has not. To achieve some perspective, it should first be 
noted that all physical systems in our universe follow 
fundamental laws of physics that can be characterized by 
equations down to the quantum level. This means that once 
we have the equations that fully characterize a physical 
system, we can predict the outcome of given input to that 
system with very high probability and accuracy. This has 
not been possible in many areas of our lives, such as 
weather forecasts made more than four days in advance, 
global warming, and the stock market, but this is more of a 
limitation of computational capacity to test mathematical 
relationships, and consequently the observablity of the 
systems, than an ability to formulate correct equations. To 
that end, as the physical systems on Earth have evolved and 
become more complex in terms of life forms, the number of 
uncertainties, dependencies, and mathematical variables has 
grown beyond our computational capabilities. 

An interesting phenomena takes place where the under- 
standing of the sum of individual interactions between the 
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system constituents not only is currently computationally 
impossible but has only a third- or fourth-order effect on the 
system behavior as a whole. For example, does the semi- 
random motion of white blood cells affect how one’s body 
might move, where the body goes, or what one does during 
any given day? No, of course not; yet although at some level 
it is important how the cells work, it is less important how 
they affect one’s daily motion. This brings into the picture 
the idea of understanding the system of constituents as a 
whole. This concept is not new, as scientists have long 
observed the phenomenon of the dynamic motion of schools 
of fish, flocks of birds, colonies of bees and ants, and large 
herds of land mammals. So, the author asks, “Why has this 
not been applied to the dynamics of a group of people 
working together, in some association with one another to 
achieve some agreed ends to their efforts?” This sounds a 
lot like a project in which a project manager would like to 
understand how it behaves (macroscopically) so that he or 
she can better understand how to manage it and come to a 
successful conclusion. Moreover, this also resembles 
physical systems for which the engineering world has 
developed highly sophisticated mathematics and models to 
not only understand the systems but to control them. It is 
this application of engineering principles to human systems 
that will better provide a physical understanding of how 
projects respond to input and how best to guide and control, 
i.e. to manage, the outcome of the system. 

2. Application of Modern Guidance, 
Navigation, and Control (GN&C) 
Principles to Project Management 

What Is Modern GN&C? 

Modeling a system as a block diagram aids in understand 
the components of that system, its inputs, and its dynamics. 
For the discussions here, given the complex nature of the 
projects necessitating the application of modern GN&C and 
multivariable control system theory, a generalized, closed- 
looped system will be used. Such a system block diagram, 
which would look at a high-level like the one in Figure 1, is 
comprised of the system dynamic model, comparison 
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Figure 1 - A generalized block model of a vehicle system 
showing the Guidance, Control, and Feedback systems. 
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function, controller, process, measurements, disturbances, 
and system response. A more detailed diagram showing just 
the Guidance, Navigation, or Control blocks is not provided 
since actual implementation of the functions can be variable 
and at the discretion of the engineer. This paper will focus 
on the functionality and how it will integrate at the system 
level. 

Open- vs. Closed-loop Systems 

Open-loop models work well for simple or well-understood 
systems such that the actual output of the system is as 
desired without feedback; e.g., a factory stamping out metal 
washers: the metal feedstock goes in, is stamped and the 
washers come out good enough without a need for a real- 
time adaptive system. 

A closed-loop system uses an analysis of the actual system 
response to a system control input to determine control 
performance of a system that may not be completely under- 
stood or be able to be effectively modeled mathematically. 

History of GN&C 

The history of GN&C, why it has been critical in 
engineering over the last 40 years, and why it is important to 
understand for large projects of today is a relatively new 
idea. But, before one can understand the relationship and 
appreciate the applicability to projects, it is first necessary to 
understand the impact of GN&C theory to the engineering 
world. 

“The origin of the terminology causes some confusion, 
particularly when reading older sources or reference not 
associated with satellites. Navigation traditionally referred 
to determining how to get a craft where we wanted it to go. 
The term guidance was introduced with rockets and missiles 
to mean computing the steering commands needed to make 
the rocket go where we wanted it to (thus, a guided missile); 
control meant carrying out these steering command to adjust 
the vehicle’s direction of flight. Thus, an intercept missile 
would have a guidance and control (G&C) system and a 
space plane or [an] interplanetary spacecraft would have a 
guidance, navigation, and control (GN&C) system. 
However, for spacecraft we use navigation to mean orbit 
determination, guidance to mean orbit control, and control 
system as a shortened form of attitude control system.” [3] 

To add some levity while yet explaining the fundamental 
principles of GN&C and recognizing that what is said is 
fundamentally accurate, we will provide the script for an 
early GN&C educational video that is widely known in the 
GN&C industry as a source of humor due to its seemingly 
obfuscated explanation of missile GN&C systems. 

“The missile knows were it is at all times. It knows this 
because it knows where it isn 't. By subtracting where it 
is from where it isn ’t, or where it isn ’t from where it is - 
whichever is greater - it obtains a difference, or 
deviation. The guidance subsystem uses deviation to gen- 
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erate corrective commands to drive the missile from a 
position from where it is, to a position where it isn ’t and 
arriving at a position where it wasn ’t, it now is. 
Consequently, the position where it is, is now the 
position that it wasn’t and it follows that the position 
that it was, is now the position that it isn ’t. In the event 
that the position it is in is not the position that it wasn ’t, 
the system has acquired a variation. The variation being 
the difference between where the missile is and where it 
wasn ’t. If variation is considered to be a significant 
factor, it too may be corrected by the GEA. However, the 
missile must also know where it was. The missile 
guidance computer scenario works as follows: Because 
the variation has modified some of the information the 
missile has obtained, [the missile] is not sure just where 
it is. However, it is sure where it isn ’t, within reason. 

And, it blows where it was. It now subtracts where it 
should be from where it wasn ’t, or vice versa. And, by 
differentiating this from the algebraic sum of where it 
shouldn’t be and where it was, it is able to obtain the 
deviation and its variation, which is called error. ” - 
author unknown 

While this can be a bit hard to follow and needs to be read a 
few times, it illustrates that getting from point A to point B 
requires the knowledge of where one is, where one wants to 
be, what is needed to get there and the importance of having 
a model for estimation and prediction. 

Why Is It Important? 

For the uninitiated it may be unclear why one might need to 
implement or even understand GN&C theory. To illustrate 
the value of this understanding and when it should be 
applied, the following analogy is provided: Take the everyday 
wheelbarrow, one uses it to hold the material placed into it 
and to move the contents under their generally graceful 
control to some predetermined location. In that situation, the 
system is comprised of an operator, the dirt, and the wheel- 
barrow. Things are pretty intuitive and well controlled and 
have a well-defined understanding of where the dirt is at any 
given time and where ultimately the location is to which 
one’s spouse instructed it to be delivered. Now to make this 
somewhat more interesting, it is requested that one place a 
front-loader on the wheelbarrow that will self-load the dirt 
and a motor so the barrow can move under its own power. It 
is also requested that the dirt be removed from the front yard 
and delivered to the operator’s mother-in-law’s flower bed 
that is across town, that delivery be operated via remote 
control ... at night. At this point, the reader can appreciate 
how much more complicated the task at hand has become, 
how much more complicated controlling this “system” to 
accomplish the task will be, how important it is to be able to 
know where the system is at any given moment, and how far 
off the system is from the desired destination. So, too, is the 
appropriate implementation of GN&C principles to Project 
Management, understanding the physical behavior of the 
system and how to control it. 


How Does It Apply to Project Management? 

Much of what has been written about Project Management 
in the last 30 years has primarily focused on the evolution of 
tools, which have proven to aid in the predictability of the 
outcome of projects. However, little has been done to char- 
acterize the discipline in terms of physical or mathematical 
models or system characterization; i.e. system dynamics. 
This lack of mathematical modeling has largely been due to 
the extreme difficulty met in being able to model human 
behavior and decision processes in terms of generalized 
equations, and is also due to the lack of the proper mathe- 
matical reference within which to frame the problem. 

To date, our ability to predict human behavior has only been 
possible through statistical analysis of outcomes of human 
behavior and performance. And to that end, human behavior 
and performance can be modeled in terms of bell-curve 
distributions [4] - whether in performance in running a mile 
or education [5], performance and fatigue while under 
stress, human performance and associated behavior, it is 
fairly predictable in this context. While some aspects of how 
this performance modeling has been applied to specific 
individual predicted performance (ranging from the 
relationships between low measured intelligence and anti- 
social behavior and genetic factors in intelligence abilities 
[6]) are still under debate, the theory itself has shown to 
track quite well as to many aspects of human performance. 
Significant understanding of human decision-making 
processes at the neural level have been made in recent years 
in artificial intelligence research [7], but human decisions 
are still largely bound by personal experience, values, 
specific real-time environmental drivers, individual brain 
chemistry, and neural firings whose outcomes are pract- 
ically limited by Heisenberg uncertainty 5 . So, given these 
variables along with the computational demand of what 
would be required to predict a project’s outcome, factoring 
in the human element, for hundreds - if not thousands - of 
individuals, it is not currently a practical approach to project 
management and forecasting. 

In much the same vein of understanding that weather does 
not rely on modeling the dynamic motion of each atom or 
molecule in the atmosphere, by looking at the problem in 
terms of systems-of-systems it is possible to see and under- 
stand the predicable and quantifiable dynamic equations of 
motions for a system. In this approach it is possible to treat 
a system-of-systems comprised of humans rather than 
mechanical components, individual machines, or computer 
processors. And, given a statistical understanding of human 
performance, it is now possible to model the “dynamics” 
and performance of the system to greater accuracy. It is 

5 Human decisions are based on neural-chemical interactions between the 
neurons in the brain, and the outcomes of these electrochemical reactions 
are what drive the higher-level brain response and subsequent decisions or 
physical responses. Therefore, at the core of Werner Heisenberg’s 
Uncertainty Principle is the fact that many decisions have their fundamental 
genesis in how molecules interact - driven by interactions of electrons - 
and our inability to measure or predict the outcome of such interactions 
without disturbing the state of the system. 
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therefore possible to define a project or program, based on 
our assumption of a system-of-systems consisting of 
humans, and to begin to model the dynamic equations of 
motion, the data required to understand the state of the 
system, the variables that are important to the control of the 
system, and our ability to guide the system to the desired 
stated of completion. 

3. Project Navigation 

What Is Navigation, and How Is It Used? 

Navigation “measure[s] position from a fixed point of 
reference (ex. landmark, north star, beacon), relative po- 
sition to a target (ex. radar, infrared, ...), [and/]or track 
movement from a known position/starting point.” [8] 

Modern GN&C uses many different methods of gathering 
the system navigational state vector 6 via an assemblage of 
sensor suites. And, following the path expressed by the 
previous wheelbarrow example, the GN&C system takes the 
information of where it is and determines whether it is 
where it needs to be. A significant portion of what the 
navigation systems does is to understand where it is and the 
accuracy of the sensor data. A fundamental part of modern 
navigation computing is the use of the Kalman 7 filers that 
employ measurements observed over time that contain noise 
(random variations) and other inaccuracies and produce 
values that are closer to the true values of the state vector by 
statistical a priori knowledge of sensor performance 
(expected error) and of the correlation of state vector 
variables [9]. Great strides have been made in augmenting 
navigation system performance and robustness in the area of 
artificial neural networks in recent years. These neural 
networks can be implemented in many ways - from 
determining which a prior model of the environment 
matches current vehicle performance, to banks of simplified 
Kalman filters [10], to artificial neural networks on 
distributed processors that detect failing sensors which are 
no longer providing sufficient information for the current 
flight regime [11]. While this marriage of statistical 
estimation and neural-network decision making is still in a 
relative infancy as compared to human ability to observe, 
determine the validity of data, and make judgments, it none 
the less defines the state-of-the-art in navigational 
computing. 

Applications to Project Management Navigation 

Knowing where you want to be in many of our project lives 
is a process of continuous, strategic reacquisition of targets 

6 For vehicles, either controlled directly by humans or autonomously, 
typical state vector variables consist of the position, velocity, acceleration 
and time at which the measurements were taken. This information is also 
measured for aeronautical or space faring systems or for systems that 
require the relative attitude of the vehicle. 

7 

In 1960, R.E. Kalman published his famous paper describing a recursive 
solution to the discrete-data linear filtering problem. Since that time, due in 
large part to advances in digital computing, the Kalman filter has been the 
subject of extensive research and application, particularly in the area of 
autonomous or assisted navigation. [12] 


due to a rapid or continuously changing economic or 
political environment. In such situations, knowing exactly 
the sate your project is critical for your project’s survival. It 
is important to know what information is needed to 
effectively understand where the system/project currently 
resides. In the Project Management world, this is known as 
the project metrics. And understanding the statistical 
significance (or accuracy) and latency (how old is the 
information and is it of importance to the project) of the 
information received is also related to determining the 
necessary project metrics. 

Tools: Sources of System Data/Project Metrics 

In vehicle design terms, the ability of the navigation system 
to understand and determine where the system is located is 
dependent on the sources of information. In terms of Project 
Management, the major advances in the theory and best 
practices over the last few decades have been in the 
development of processes and tools to provide better insight 
into the health and status of the project. Or, in other words, 
“Are we where we want to be? If not, how far off are we? 
And how reliable and timely are my project metrics?” 

As discussed earlier, it is important to have the appropriate 
information to determine the status and progress of a project 
and such tools as Gantt charts, critical paths, resource- 
loaded schedules, earned value management (EVM), full- 
cost accounting, known risks, and mitigation plans, to name 
a few, are all examples of recent advances in determination 
of what information is typically most useful to understand 
the state of the project (in engineering terms, the state vector 
of the system). On the “softer side” of Project Management, 
important project metrics are: team morale and relevant 
local, national, and international news. 

(1) Gantt Charts — Henry Laurence Gantt (1861-1919) 
was a mechanical engineer, a management consultant, 
and an industry advisor. He developed Gantt charts in 
the second decade of the 20th century as a visual tool 
to show scheduled and actual progress of projects. 
Accepted as a commonplace Project Management tool 
today, it was quite a radical concept and an innovation 
of worldwide importance in the 1920s. Gantt charts 
were first used on large construction projects such as 
the Hoover Dam, the construction of which started in 
1931, and the US interstate highway network, the 
construction of which started in 1956. [13] 

(2) Resource-loaded Schedules — were developed to better 
predict the required resources and task durations to a 
low-level resolution at the beginning of a project to 
help avoid gross misestimations on the life-cycle cost 
of the project. And, depending on the size of the 
project, they can be a useful tool to keep a real-time 
knowledge of the end-of-project cost estimates or can 
be used to make very informed, real-time scope vs. 
resources vs. project schedule decisions. However, as 
has been seen time and time again, the larger the 
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project, the larger the standing army that is required to 
feed and maintain a detailed resource-loaded schedule. 

(3) EVM — The genesis of EVM, which occurred in 
industrial manufacturing at the turn of the 20th 
century, was based mostly on the principle of “earned 
time” popularized by Frank and Lillian Gilbreth, but 
the concept took root with the DuPont Corporation and 
General Dynamics in the 1950s and later in the US 
Department of Defense in the 1960s. The original 
concept was called PERT/CSCSC [program evaluation 
and review technique/cost schedule control system 
criteria], but it was considered overly burdensome (not 
very adaptable) by contractors who were mandated to 
use it, and many variations of it began to proliferate 
among various procurement programs. EVM is able to 
combine performance measurement and management 
tools that integrate technical (progress on scope of 
work), cost (actuals tracked by work breakout structure 
[WBS]), and schedule parameters (milestones as a 
measure of the earned value of the scope of work 
completed) of a contract. [14] 

(4) Risks and Mitigation Status — The fundamentals of risk 
management are centered on quantifying any potential 
risks that might affect a project, identifying the 
consequence if a risk occurs vs. its likelihood to occur, 
and the plan to mitigate the risk to a manageable level. 
Understanding risks to a project and actively managing 
those with the greatest threats are critical to avoiding 
any unforeseen (did not bother to look around and see 
the hungry tiger) or ignored (proverbial ostrich risk 
management approach) risks. [20] 

(5) Morale of the Team — Maintaining an accurate reading 
on the morale of a team is critical to the success of the 
project and the project manager. Team morale can be 
affected and shaped by not only the direct actions of 
the project manager but by peer influences, news from 
the outside, and perceptions of both the present and the 
future. Team morale can also be influenced by the type 
of work being asked of the team’s members, the pace 
at which they are expected to perform, whether they 
feel the work is meaningful, and whether they are 
fairly compensated for their labors. All of these factors 
will influence individual performance and, ultimately, 
the performance and productivity of the team as a 
whole. This, therefore, is one of the critical project 
performance inputs that is required to effectively 
manage a project and can only truly be obtained by 
personal relationships with the team and by “managing 
by walking around” (MBWA) 8 and talking to people. 


Dave Packard and Bill Hewlett, in the early days of Hewlett-Packard, 
devised an active management style that they called MBWA in which 
senior managers were seldom at their desks and spent most of their days 
visiting employees, customers, and suppliers. The MBWA concept was 
popularized in 1985 by a book by Tom Peters and Nancy Austin. Japanese 
managers employ a similar system, which originated at Honda, and is 
sometimes called the 3 Gs ( genba , genbutsu, and genjitsu, which translate 


(6) The News and Trusted Sources of Information — Team, 
corporate, industry, local, national, and world news all 
can be very important project control inputs 
influencing anything from previously mentioned team 
morale to project risks (technical, scope, financial, 
etc.), to funding possibilities, or to sales growth poten- 
tials, to name a few. Much as a systematic approach 
was taken to identify the risks to the project, the same 
diligence should be taken to understand the influential 
information and received updates in a timely fashion 
for the project. As discussed later in the Project Control 
section, the timeliness of project input into the system 
from outside is just as important to project perform- 
ance as the timeliness and frequency with which 
project corrective inputs are made by the project 
manager. For example, not consulting the stock market 
trends and futures on advanced technology before 
committing significant project or company resources 
can be a recipe for disaster, just as would be com- 
mitting a standing army to launch the space shuttle 
while not consulting the long-range weather forecast 
and not knowing a hurricane was bearing down on 
Florida. While there is little protection against the 
“unknown unknowns” out there, without a reliable 
crystal ball, some amount of effort can reduce many 
surprises in a project’s life. 

4. Project Guidance 

What Is Guidance, and How Is It used? 

The guidance system in the engineering world is sometimes 
at best hard to distinguish from the navigation system due to 
tightly correlated functions and how they are implemented 
in the final design. However, from a theoretical and an 
engineering discipline perspective, the two systems are very 
different, and guidance theory can best be described in 
terms of implementation in a flight vehicle as: 

“Guidance [system], which leverages navigation data 
and target information to direct flight control ‘where to 
go’. Guidance is the ‘driver’ of a vehicle. It takes input 
from the navigation system (where am I?) and uses 
targeting information (where do I want to go?) to send 
signals to the flight control system that will allow the 
vehicle to reach its destination (within the operating 
constraints of the vehicle). The ‘targets’ for guidance 
systems are one or more state vectors (position and 
velocity) and can be inertial or relative. During 
powered flight, guidance is continually calculating 
steering directions for flight control. For example the 
space shuttle targets an altitude, velocity vector, and 
gamma to drive main engine cut off.” [8] 

All of the guidance tools available at a project manager’s 
disposal are to drive down the delta in project status, as 
determined by navigation function, and to calculate what 
needs to be done to get the project on a corrected course to 


into “actual place,” “actual thing,” and “actual situation”). [15] 
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reach final programmatic goals. An ability to predict the 
future and to have a state vector and accurately integrate it 
forward in time is critical so that accurate guidance can be 
formulated and applied. 

Fault Tolerance - What Happens If You ’re Not Omniscient? 

Even in the world of engineering, protecting the system 
from the unknown unknowns out there has been slow and 
complicated to implement into practice: “Conventional 
GN&C brings a mature understanding of dynamics and 
statistical modeling, measurement and estimation, control, 
planning, optimization, and other design elements - in each 
case grounded in solid theoretical foundations. But fault 
tolerant GN&C has a different story to tell. Many lessons 
have been learned over many years and many projects 
(usually something like, ‘Don’t do that again’), but progress 
has been slow. Theoretical grounding for fault tolerance, as 
generally practiced, has significant ground to make up in 
comparison to its conventional cousin.” [16] So, it is within 
Project Management and how the project is structured and 
controlled that we are able to tolerate and respond to the 
unknown unknowns that continually bombard our projects 
and are impossible to predict. 

Rasmussen’s words could not be more appropriate to the 
discussion at hand and the importance in addressing Project 
Management in this new way: “This is of particular interest 
now, because in many ways we have reached the end of an 
era, where it might be said that customary methods have 
been carried to their logical extreme. In fact, by some 
assessments, standard [fault-tolerant] design is in crisis, as 
the same litany of problems recurs on project after project 
(late delivery, fragile behavior, poor operability, incomplete 
testing, and so on) - and this is before considering the impli- 
cations of new mission types that will push even harder. 
Solutions are not likely to come merely by polishing 
existing methods, starting them earlier, integrating them 
better, or wrapping them within tighter processes. The roots 
of the problem are deeper than this, so a different path is 
required.” [16] 

NASA has adopted and exercised many of the different 
principles of Project Management and control over the years 
from “build the hardware to get us there and we’ll let the 
paperwork catch up” of the Apollo era, to the Constellation 
Program (CxP), which implemented full-cost accounting, 
EVM, ISO (International Organization for Standardization) 
practices, and rigorous systems engineering practices and 
models. However, in the final analysis the time or cost of 
the programs has not been significantly reduced, and it is the 
author’s opinion that some of the principles are not conducive 
to implementation within government or have diametrically 
opposing goals with competing process implementations 
when implemented in a textbook fashion. 

To cite a few examples: While textbook systems engineering 
principles and practices with detailed processes, require- 
ments, documents, interface management, drawings, and 


working groups ensure all design decisions are compliant 
with requirements for the final product and a deliberate 
change management process, this method also does not lend 
itself to a project that must respond dynamically to changing 
requirements, requires rapid turn around in both design and 
prototyping, needs small and highly effective teams, or faces 
uncertain future funding; yet it is reinforced in an 
environment in which any failure is not tolerated. EVM, 
while also seemingly effective in the private sector as a 
management tool for projects for which funding has been 
budgeted and assured for completion of a project, is not the 
environment in which government programs live. Most 
government agencies and projects cannot be assured any 
funding past the current fiscal year boundary. Conforming 
to the best practices of EVM also requires a small standing 
army to feed the financial and resource-loaded scheduling 
tools that conflict with smaller budgets, small dynamic 
teams, or project schedules that outpace the ability of a team 
to input data into the systems. 

The intent of this discussion is not to disparage some of the 
latest theories in Project Management best practices, only to 
emphasize three things: 1) Not all problems require a 
hammer; 2) If you only have a hammer, all of your 
problems look like nails; and 3) Situations will arise in 
which your system does not respond the way you expected 
and your tools are not providing the information you need. 
So to that end, we must engineer our projects to be fault 
tolerant to survive the unknown unknowns and provide 
guidance in situations in which our tools are either not 
providing the information we need or not providing it in a 
timely manner. 

5. Project Control 

What Is a Control System, and How Is It Used? 

The following quote very well summarizes why the study of 
control theory and control systems is important in the world 
of engineering and also addresses the premise of this paper 
and the application to business and Project Management. 

“Control engineering is based on the foundation of 
feedback theory and linear systems analysis, and it 
integrates the concepts of network theory and com- 
munication theory. Therefore control engineering is 
not limited to any engineering discipline but is equally 
applicable for aeronautical, chemical, mechanical, 
environmental, civil, and electrical engineering, For 
example, a control system often includes electrical, 
mechanical, and chemical components. Furthermore, 
as the understanding of the dynamics of business, 
social, and political systems increases, the ability to 
control these systems will also increase.” [17] 

In theory, the vehicle control system will accept guidance 
commands (influenced by knowledge of the current state of 
the system as provided by the navigation system) to effect 
change in aerodynamic and/or engine controls. In managing 
a program or a project, the need to understand your end state 
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or goal (the guidance system) while very important is only 
one of three legs to the GN&C stool. Knowing where you 
need to be (the project guidance system) based on project 
status and performance metrics (the project navigation 
system) now culminates in affecting change in the project 
based on input from the other two and knowledge of the 
physical response characteristic of your project. In terms of 
a physical system, using the knowledge of how the system 
responds to inputs (dynamic response due to the equations 
of motion), the system calculates the required inputs to 
command the system “effectors” to place it on a corrected 
course. 


system does not guarantee a successful project, but it does 
increase the opportunities for success. 

Defining the Project Control Variables 

To define system/project control variables/inputs, we must 
gain knowledge of what the control inputs are to the project 
and when and to what degree input is required to get the 
desired effect via system output that is measured using 
project metrics. One example, borrowed heavily from the 
terminology of the GN&C modeling world, will be provided 
to illustrate how this would be applied mathematically to a 


Control systems engineering activities, which are multidis- 
ciplinary in nature, focus on implementing control systems 
which are mainly derived by mathematical modeling of 
systems of a diverse range. The development of semi-/fully 
autonomous vehicles that largely self-regulate the system by 
adapting to environmental inputs into the system, unknown 
vehicle performance responses, and even new goal states is 
at the cutting edge of control system technology. Some 
examples of such systems are: self-tuning controllers if the 
process behavior changes are due to aging, drift, wear, etc.; 
adaptive controllers for nonlinear or time-varying processes; 
and adaptive or self-tuning control of multivariable 
controllers for multivariable processes (an example would 
be multiple input, multiple output [MIMO] systems). 

Control systems are used to achieve efficiency and some 
level of automation to improve productivity and/or product 
quality or to obtain a desired level of automatic/autonomous 
control. As in the world of machines and vehicles, the need 
for dynamic change in a project control system as a response 
to a morphing project, its dynamics, inputs, weightings, 
size, etc., has to be able to change the project controls as the 
project changes to facilitate efficient system performance 
and product quality. Dorf and Bishop further illustrate this: 

“. . . it has become interesting and valuable to attempt to 
model the feedback processes prevalent in the social, 
economic, and political spheres. This approach is 
undeveloped at present but appears to have a reasonable 
future. Society, of course, is composed of many feed- 
back systems and regulatory bodies, such as the Federal 
Reserve Board, which are controllers exerting the 
forces on society necessary to maintain a desired 
output.” [17] 

Open-loop vs. Closed-loop Project Control and 


Figure 2 - A simplified system block diagram 
representing the different system aspects as linearized 
equations in the frequency domain. 


project using a simplified version of Figure 2 (a simplified 
version of Figure 1) in which different parts of the project 
have been replaced with variables to help provide the next 
level of understanding of the system. The input variables, 
commonly from the guidance system, are represented by 
R(s), the output of the system by C(s); the feedback function 
by H(s) as performed by a sensor suit or Navigation system 
(depending on the complexity of the system), and the 
system’s transfer function by G(s). Two important things to 
notice here are: first, the system transfer function, a 
mathematical model of the system dynamics, is typically in 
the form of simultaneous differential equations 9 . The system 
transfer function relates system inputs to system outputs. 
Second, the differential equations are generally difficult to 
work with when developing a control system and, therefore, 
are replaced with Laplace transformation equivalents that 
reduce the mathematics to a set of linear algebraic equations 
represented by the (s) notation. While it is not the scope of 
this paper to show how to model your project through a set 
of differential equations, it is worth noting how the general- 
ized model is arranged and that you can begin observing 
how the input to your project impacts the output. 


Likely Outcomes 

Open-loop projects are subject to the gods of entropy and 
luck. They typically run unbounded or have managers who 
systemically overreact, causing negative input or “pumping” 
into the system resulting in an uncontrollable project and 
system collapse. Closed-looped systems have a feedback 
mechanism, which is a measure of the system’s response to 
input, that allows further tweaking of system inputs to gain 
better control authority of the system or the project. Such a 


However, for a generalized model of a project, we will use 
the textbook example of a spring-mass-damper mechanical 
system. The time domain representation of this is system is: 


F =F +F 

Total oscillatory damping 


(i) 


Dynamic equations of motion that model real-world systems are a 
function of time, noted by (t). The movement of an object through space 
and time is how humans denote the change in a system’s state or position. 



where total force ( F Tota/ ) is equal to system oscillatory force 
{F oscillatory) plus damping force (F damping ). The equation can 
be expanded to include system representation of the mass, 
springs, and dampers to 


M dMl +c M<l +m)=0 


dt l 


dt 


( 2 ) 


where: M = mass of the system 

y(t) = is the time-varying vertical displacement 
of the mass 

c — is the dampening (friction) constant 
K — is the spring constant 


Equation 2 can be further simplified to 

MW+cX+Kx=0 (3) 



Figure 3 - Plot shows the system response to varying 
values of the dampening coefficient where C, — A is 

defined in the above figure- 

Plot attribution: Created by a MATLAB script and 
provided by Nmnogueira at en.wikipedia 


where: W = system acceleration 

= system velocity 
□ x = system position 

j Now dividing by the mass of the system and defining the 
~ following variable that models natural frequency of the 
system, 6) 0 , and the dampening coefficient, /l, we get 

W+2A(v 0 $+ co^x = 0 (4) 



— ^ Equation 4 can then be taken into the Laplace domain to 
solve for roots of the system that will characterize system 
p stability. The full derivation of the differential equation 
solution can be seen in [17], but response to this system 
with varying dampening coefficient can be seen in Figure 3. 
When the dampening coefficient equals 1, we see the system 
quickly and smoothly approach the new system state given 
an input. If the coefficient is greater than 1, we see the new 
system take much longer to approach the new state, so it is 
considered over-damped. For systems that are considered 
under-damped, we see the coefficient is less than 1 and can 
oscillate to the point at which the system can fall apart or be 
uncontrollable. 

The moral is to “Understand Your Dampening Coefficient of 
Your Project”: If your system is under-damped - usually via 
poor or over-reactive leadership (leadership overreacts to 
events or team members do so, respectively) - your project 
will expend wasted resources, burn out people, or vibrate 
out of control and fall apart. If project leadership is too 
conservative, this can result in the project taking too long to 
reach a new and desired state for the project. And, in 


business terms, that could mean millions of dollars of lost 
revenue because the competition arrived at the solution first. 

It is also important to understand how you can determine 
what your dampening coefficient is and what the constitu- 
ents mean in terms of project control. Using equation 4, we 
see it in terms of current position, velocity, and acceleration 
of the team where the natural frequency, Q) 0 , is a function 
of spring constant (or natural dynamic of the project), K, 
and the mass, M, is the size of the project or team. And, the 
dampening coefficient, /l, is in terms of damping constant 
(or friction constant) and can jjtp considered a summation of 
the resistive forces working against the team or decisions of 
the project manager. These resistive forces can be quantified 
in terms of schedule or dollars (one is a function of the 
other); impact due to disagreeable personalities; counterpro- 
ductive policies, taxations, built-in process delays, project 
change control, fiscal uncertainty or change, etc. So, we can 
think of the dampening coefficient in total terms of the force 
of project resistance divided by two times the square root of 
the mass of project times project’s natural dynamics. While 
this is a dimensionless ratio, the ratio does give more of an 
intuitive response to a project given a new input and a way 
to understand a project’s response and areas to investigate 
for change that would allow tuning the project’s dampening 
coefficient to produce a more desirable response to change - 
which in this case could be changing the size or the culture 
of the team. 

Traditional Project Control Variables 

Specific project control variables can change depending on 
the project, but traditional high-level control variables are 
(vehicle analogies in parentheses): resources (fuel), scope 
(vehicle functional capabilities or mission profile), project 
status and authority (attitude determination and control), and 
schedule (thrust, velocity, etc.). 

One example of a method of a project control is project 
change control, which controls the time-based variable nature 
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of the change in the system. Whether controlling the change 
in the project end state (e.g., configuration control of prod- 
uct requirements) or the time -varying equations of motion 
for the system (e.g., understanding and controlling how the 
project is structured and changes over time either through 
change control boards, deliberate organization restructuring, 
or new or changing customers and their inputs), this, too, 
should provide an emotional response to the experienced 
project manager who has worked on projects with too much 
change control for what the project required. The effect of 
this was a system that was over-constrained (over-damped), 
and it almost required an Act of Congress to get changes 
approved through the systems. Many have experienced the 
corollary in which there was insufficient project change con- 
trol and significant amounts of lost productivity due to 
rework or a lack of configuration management - effectively 
resulting in an under-damped system. It is important to 
understand the correct amount of project change control for 
the system and to be able to use it to maximize productivity, 
which is not to be viewed as an impediment. 

Control Authority 

Control authority is the capability of the control system to 
overcome disturbance forces that are moving the system out 
of the desired trajectory. This paper will not go into deriva- 
tions of the control authority of vehicles due to the specific 
and intrinsic dynamic equations of motion of vehicle 
effectors and the response to the system, but rather will pro- 
vide an understanding in terms of Project Management. It is 
a project manager’s ability or the project control functions - 
e.g., project change control, processes, procedures, etc. - that 
affect change of project direction or schedule. It is critical to 
understand early on whether the appropriate delegation of 
authority is in place to affect change, be it on an individual 
responsibility level or at a board or panel level. 

Attitude Determination and Control 

Attitude determination (provided by the navigation system) 
and control are dependent on the accuracy of attitude sensors 
and the control authority of your vehicle or project. While 
the equations of attitude torque (method to control external 
torques [adverse external inputs that steer a project in an 
undesirable direction] or used as a project steering function) 
will not be discussed here, they can be found in [3, p. 307]. 
Relating back to control authority, it is important to under- 
stand whether your project has the ability to affect a course 
correction due to external forces. An example may be 
having sufficient management budget reserves to counteract 
annual funding shortfalls, labor surge capability to address 
unknown issues or seasonal demands, or even an ace public 
relations team to counteract the voices of the competition. 

If you cannot tell which way your project is pointing, get- 
ting to your destination can be problematic at best. If you 
also cannot adjust the direction in which your project is 
heading (project direction control authority cannot over- 
come or counteract the disturbance forces), missing your 
target is guaranteed. 


6. Implementation on the CxP Space suit 
Project 

The initial mission of the CxP was to provide U.S. access to 
the International Space Station and then develop the 
transportation infrastructure and capability to perform sortie 
missions to the moon in preparation for human missions to 
Mars. In formulating the CxP design reference missions and 
architectures for different hardware elements, the develop- 
ment of the space suit architecture evolved into a suit that 
was modular and could be reconfigured during the mission 
to meet the needs of current mission objectives. The goal 
was to reduce launch mass by limiting the number of suits 
each astronaut had to take - given that historically a crew 
member would have a specific suit for a particular environ- 
ment. The space shuttle crew provides a good example of 
launching two suits per crew for those who are launching in 
the orange advanced crew escape suits (ACES) and then a 
subset of the crew who will perform extra-vehicular 
activities (EVAs) will also launch with the big, white EVA 
suits (ISS EMUs). The new approach taken by the NASA 
CxP Suit Element Team was something that had not been 
undertaken before and, therefore, required a new way of 
approaching the problem and a new way of doing business. 

From the onset of the project and the formulation of the CxP 
Suit Element acquisition strategy, it was planned that to 
save schedule time a NASA team would develop the suit 
architecture, expand associated requirements, and perform 
the preliminary design in parallel with the prime contractor 
(which would finish designing the suit and building the flight 
hardware) selection and putting contracts into place. With 
this approach, it was evident that the project team, the way 
the team was managed, and the associated tools would need 
to be dynamic and flexible. To that end the author’s exper- 
ience with modern adaptive GN&C and experience with 
large NASA programs and how they could be integrated 
came into play in leading the CxP Suit Element engineering 
team such that, during the five years the team never overran 
its budget and was only responsible for a two week schedule 
slip during the project’s second year. All the while, the team 
implemented all of its mandated NASA and CxP project 
control requirements: implementation of EVM, WBSs, 
resource-loaded schedules, a textbook systems engineering 
approach, and program reporting. The team also led many 
other NASA teams in setting up and using mandated 
document control systems as well as developing project 
control processes and structures. 

The team, in the earliest days of the CxP space suit project, 
was required - due to an already aggressive CxP schedule - 
to develop a first revision of functional design requirements 
within four months not only to support program-approved 
System Requirements Review milestones, but also to have 
the requirements available for the release of prime contract 
request for proposal. For the team to succeed it was impera- 
tive that it operate as a high-performance team and be 
managed as such. And, like high-performance aircraft, so, 
too, the principles applied in its management. 
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In high-performance aircraft, the typical mission profile is 
dynamic and fast paced, so it is imperative the pilot know 
exactly the aircraft’s position, velocity, and attitude in real 
time, otherwise the mission objectives or the life of the pilot 
may be in jeopardy. This, in turn, defines the type, quality, 
and speed and accuracy with which the aircraft’s avionics 
collect and provide this information. While it was fairly 
certain that none of our team members were in such dire 
danger - besides the occasional tongue lashing - the need 
for real-time status of the team and an accurate assessment 
of progress status was critical. The team operated on a well- 
defined weekly process [18] for developing, reviewing, 
analyzing, editing, and approving element and subsystem 
space suit requirements. Status was provided to the project 
manager (the author) at an early morning tag-up in which 
any issues or roadblocks were discussed, and through the 
day as the project manager walked around to the different 
subsystem teams and then at the close-out tag-up at the end 
of the day on Fridays. 

An unreported problem that might result in a schedule slip 
of just a day or so was an unacceptable outcome, given the 
extremely success-oriented schedule under which the sub- 
system teams operated. As with high-performance aircraft, 
the subsystems had to work well independently, commun- 
icate with other subsystems, and communicate on prescribed 
schedules to the project manager who, in turn, had to assess 
the information and provide a guidance update to the team 
and produce the desired product to the agreed-to schedule. 
Information had to flow frequently and accurately across the 
subsystems, up the management chain and down to the 
working troops with the metrics needed being meaningful to 
the tasks at hand being managed. This is where the system- 
of-systems approach came into play with guiding and 
managing subsystem teams that operate independently as 
possible while exchanging information frequently with 
sister subsystems and working in concert with one another. 

Some might say, “How is this any different than any other 
high-performing, rapid response team?” To that the answer 
is given: In this situation, the team was formulated; and the 
process by which it would operate, communicate, and share 
information as well as its latency and applicably to what 
was being controlled were modeled and documented in the 
very same way a vehicle’s GN&C system would have been 
designed - even down to understanding the mass, spring 
constant, and friction coefficient quantities of the team. 
And, the subsequent damping response of the team was used 
to modify the processes and limit the size of the team based 
on the unique team dynamics. At the end of four months, 
the team had met the schedule deadline and delivered the 
first 500-page version of the CxP Suit Element requirements 
document [19]. While there was a requested subsequent two 
week stand down to perform an internal review to ensure the 
team did not move too fast to deliver a quality product, it 
was found that no changes were necessary. During the four 
years subsequent to this activity, the requirements document 
was only revised three times as it was required. 


Once the initial requirements generation phase of the project 
was complete, the team moved into a requirements valida- 
tion testing, analysis, and preliminary design phase that was 
less demanding in terms of schedule but challenging none 
the less. At this point, the team structure, the way in which 
it was controlled, its project metrics, and how guidance was 
applied to it were revamped to meet the new operational 
environment and expectations. 

Since the Suit Element was required to report budget and 
schedule actuals monthly, an internal monthly review prior 
to the formal review but, due to the pace of the project team 
status, conducted with less latency was required for internal 
management. Therefore, early Monday mornings the project 
manager would meet with subsystem leads to get the weekly 
status and perform short-term planning as necessary. At 
these weekly tag-ups, on a rotating basis, each subsystem 
would have its schedule and corresponding status reviewed 
with the project manager and other subsystem leads. On 
Tuesday mornings the entire team, spanning multiple sup- 
port contracting companies and two NASA centers, would 
have a one-hour integrated-team status meeting that would 
then be followed by a meeting of the Suit Element Control 
Board at which baseline architecture, requirements, project 
scope, and schedule planning packages were controlled. The 
structure added by the control board provided the majority 
of the system dynamic response for the team and the 
Monday morning tag-ups with the leads acted as the system 
caution-and-warning system. The new dynamic response 
(spring-mass-damper behavior) of the team was also 
updated and reflected in the project schedules and planning 
packages. Successful implementation of this is evident in 
the afore-stated budget and schedule performance history of 
the suit project. 

Control of the team and its associated tools, processes and 
information was set up in accordance with not only what 
was mandated by NASA but also under the GN&C control 
principle that a control system’s model of systems dynamics 
must represent how the input corresponds to the desired 
output and subsequent system performance. Beginning with 
the required implementation of EVM, the team created the 
WBS dictionary for different development phases of the 
project. The resource-loaded schedule was then structured to 
map to the WBS, as were the funding, charge codes, and 
risks. Project managers have effectively three large levers to 
pull on to control a project: scope, schedule, and funding. 
So, the system put into place would have the scope, via the 
schedule, respond to a change in funding. Similarly, the 
effects of either of the other two were affected by a change 
in the third 10 . While this is not a new concept, it was set up 
so there was a direct correlation that was more quantitative 
than intuitive that, at a high level, can be equated to control 
of a vehicle’s position and velocity mission activities. 


It should be noted that the risk mitigation plans were tied to the 
appropriate WBS which were linked to the budget planning and schedule; 
effectively linking the risk mitigation plans to the base-line budget and 
schedule. 
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Lower-level processes and statuses were also performed 
based at the planning package level, but on work actually 
under way; these were implemented and internally referred 
to as Requirement Analysis Cycles (RACs) and Design 
Analysis Cycles (DACs). At this level, they were managed 
in terms of progress management rather than managing to a 
detailed Gantt-chart schedule. This lower-level progress 
management, to employ a vehicle analogy again, was used 
to ensure and measure the health of the subsystem and the 
quality of the products or output - similar to a vehicle Inte- 
grated Vehicle Health Monitoring (IVHM) system. And, 
even at this level the latency, the subsequent observed 
system response per equations discussed before, was used to 
adjust and develop new reporting frequency and tools. One 
such tool, the DAC Tracker™ 11 , was developed using 
Google Docs. DAC Tracker™ is located in the Google 
computing cloud, allowing multiple people to update simul- 
taneously, and the document can be exported into the format 
used by the team’s software for reporting. So now the 
subsystem status gathering latency went from greater than a 
week to a matter of hours. This report was reviewed each 
Monday with the leads and project manager for all 
subsystems so that lowest-level issues could be addressed 
on a weekly cycle and any needed subsystem-to-subsystem 
integration could take place. 

The DAC Tracker™ is an example of how the team’s 
responsiveness to input, X, was observed and indicated an 
under-damped system - system took longer than expected to 
reach a desired goal/state and the team dynamics were 
adjusted to gain performance. Previously the RAC/DAC 
status were gathered once per month per subsystem. If an 
issue was identified in a subsystem review it might be over 
a month before the next status update was provided and 
some measure of effectiveness reported. By implementing 
the new reporting process and frequency, it increased the 
number of opportunities to gather information regarding the 
effectiveness of a system guidance correction (control input) 
from 1 1 opportunities to roughly 50 in any given subsequent 
12 months. 

Detailed workings of the change, document control, and risk 
mitigation processes will not be addressed here; however, 
the same general philosophy was used to understand their 
purpose and how they affected dynamics and responsiveness 
of the team, thereby allowing individual needs tailoring. 

7. Conclusions 

It has become more and more evident, in the many areas of 
science and biology in which the study and understanding of 
natural systems and processes and how the human body 
works - e.g., what makes us human vs. mammalian - that 
more insight into the fuzzy line between where physics and 
biology drive our decisions and actions is vital. Similarly, in 
the studies into how to control vehicles and systems and the 

11 SmithOps (www.smithops.com) was contracted to provide the schedule 
management and reporting for the Suit Element. 


study of artificial intelligence, we are learning more and 
more about how we as humans behave, the acquisition and 
processing of information, and the processes required for 
formulation of thoughts and decision making. 

The results of recognizing the applicability of a GN&C 
system-of-systems management approach to the CxP space 
suit project and implementation were seen over the 5 years 
of the project: a team contribution to schedule slip of only 
two weeks 12 , annual budgetary under spend of 5% or 
greater, an order of magnitude decrease in review item 
discrepancies at space suit team’s system requirements 
review 13 , all the while performing approximately 130 com- 
ponent and suit-assembly hardware tests, four revisions to 
the configuration managed Suit ERD, and the completion of 
approximately 180 peer-reviewed design white papers and 
engineering memos. The key items to understand and help 
frame the significance of the metrics above are the very 
dynamic nature of the CxP scope, aggressive schedule, 
funding challenges and that the suit team was formulated 
more than two years after the Orion vehicle, of which the 
suit hardware had to integrate with and be certified for flight 
for launch that same as Orion. This effectively placed the 
suit project two years behind from the very beginning, 
presented project-to-project integration challenges - all 
within a very dynamic project scope environment. But by 
utilizing the principals defined in this paper, the suit team 
was able to adjust to the changing environments and target 
end states, and was postured 14 for a suit preliminary design 
review PDR to meet the needs of the Orion project and the 
CxP. 

In reviewing the material presented in this paper, a clear 
mapping of traditional system-of-systems, which are com- 
prised of machines and vehicles, is similar in complexity 
and behavior to many of the large and complex project and 
teams of today. We also now recognize that many of the 
engineering principles and mathematics behind the GN&C 
systems can be used to understand how the programs and 
projects of today can respond, and how they can be better 
managed by knowledge of their mathematical modeling at 
the conceptual and intuitive level. We are standing on the 
edge of a new future of how projects are characterized and 
managed in the 2 1 st century - much in the same way that the 
theory and mathematics behind GN&C in physical systems 
blossomed in the early 20 th century, evolving from a 

12 

The CxP space suit experienced many schedule slips to milestones, but 
these were due to re-alignment of project schedule within the CxP and in 
response to funding changes outside the control or responsibility of the 
space suit team. 

13 The results of this approach was an order of magnitude reduction of 
review comments/Review Item Discrepancy (RIDs) against the Suit 
engineering requirements document (ERD) compared to the number of 
RIDs against the parent system requirements document. For the Suit ERD 
SRR, 0.38 RIDs were received per Suit system requirement. In 
comparison, the parent document had a 2.94 RID to requirement ratio at the 
EVA system SRR six months prior. 

14 

The presidential prioritization of NASA’s activities in February of 2010 
significantly changed the scope of the CxP program and all projects within; 
necessitating a review of architectures and a delay in the suit PDR. 
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practice of empirical design and test engineering to one of 
highly reliable mathematical modeling and design of highly 
complicated vehicles and systems. 

It is the proposed future that we can take the art of Project 
Management, as described once by a project manager as . 
herding cats in the rain, blindfolded, all the while trying to 
keep the dogs which are tied to your waist from eating the 
cats!”, to an environment in which the project manger will 
know when the rain is coming, see over the horizon, know 
statistically how the cats are likely to behave, and command 
the dogs such that the dogs are autonomously controlling 
the herd in much the same way as a well-trained border 
collie expertly delivers its herd with minimal-to-no input 
from a shepherd. By characterizing project dynamics in 
terms of mathematics, it is thus possible to factor out the 
uncertainties in internal response and behavior of a project 
and limit uncertainties to the unknown nature of the external 
inputs, and how the project will respond and adapt to these 
inputs. Increasing the predictability of project performance 
and response will reduce project uncertainty in cost 
associated with schedule and can also lend itself to the 
tuning of project processes that will be further realized in 
performance and cost savings. 

On a final note, while the scientific, mathematical, and 
engineering techniques discussed in this paper are valuable, 
an exceptional project manager will add the strong leader- 
ship skills: intuition, courage and commitment to the 
project. 
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